home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001178_ccprl@xdm001.c…ranfield.ac.uk _Tue May 25 10:37:45 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA29871; Tue, 25 May 93 10:37:45 MET DST
  4. Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA09914; Tue, 25 May 1993 10:59:06 +0200
  6. Received: by xdm001 
  7.     id AA05842; Tue, 25 May 93 09:58:59 +0100
  8. Received: by xdm039 (5.57/4.7) id AA10944; Tue, 25 May 93 09:58:55 +0100
  9. Message-Id: <9305250858.AA10944@xdm039>
  10. To: www-talk@nxoc01.cern.ch
  11. Cc: ccprl@xdm001.ccc.cranfield.ac.uk
  12. Subject: Authentication of published docs
  13. In-Reply-To: Your message of "Mon, 24 May 93 19:17:48 BST."
  14.              <9305241817.AA13007@xdm001> 
  15. Date: Tue, 25 May 93 09:58:54 BST
  16. From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
  17.  
  18. > There needs to be a major infrastructure of authenticating and authorizing
  19. > capabilities on the Internet to support "publishing."  It is not simply a
  20. > question of client/server (consumer/producer) because the model does not scale.
  21.  
  22. Well put. At Cranfield we are interested in the first instance in
  23. restricting a small area of our web to privileged local users only;
  24. simple Kerberos 4 will do that fine. In the future, however, we
  25. definitely want electronic subscription to journals etc, which requires
  26. widespread the authentication described. However.....
  27.  
  28. > The idea here is that Kerberos by itself is not an authentication
  29. > service.  It is a mechanism which can be used to develop such a service.
  30.  
  31. No. What you just described was (effectively) cross-realm
  32. authentication, and the authentication in your example *did* happen via Kerberos!!
  33.  
  34. ServerB has to contact serverA, and ask it for credentials for aUser.
  35. ServerB can only trust those credentials if the servers trust each
  36. other (or at least B trusts A), so each must hold a key for the other's
  37. TGT service. This requires that their administrators communicate the
  38. keys out-of-band (just like a new user being verbally told their inital password).
  39.  
  40. It's impractical for every Kerberos server to exchange tickets with
  41. every other, so there needs to be a hierarchy, just like the domain
  42. name scheme (especially since kerberos realms are conventionally
  43. domains name UPPERCASED) - so, if want to authenticate to ORA, I do so
  44. by a multi-hop authentication - cranfield shares keys with a UK auth
  45. server, which shares keys with a US auth server, which shares keys with
  46. ORA. As a detail, the actual servers themselves don't actually talk;
  47. like DNS, each passes a reference and a ticket back to the client,
  48. which then talks to the next server in the chain.
  49.  
  50. Cross-realm authentication is well understood, and is not limited to
  51. electronic publishing. However, I think the lack of an application
  52. which needs cross-realm authentication has limited it's use and not
  53. justified large-scale organisation. Hopefully, WWW is that app. If they
  54. aren't doing so, I implore ORA not to re-invent this particular Kerberos wheel.
  55.  
  56. Peter Lister                                    p.lister@cranfield.ac.uk
  57. Computer Centre,
  58. Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
  59. Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875